Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(sanity): display release errors #8482

Merged
merged 7 commits into from
Feb 7, 2025

Conversation

juice49
Copy link
Contributor

@juice49 juice49 commented Feb 3, 2025

Description

This branch adds release errors to the data model and updates the UI to reflect the presence of a release error. Presence of an error is only taken into account for releases that are in an active state.

This branch does not include a way to deal with a release error. We'll likely want to allow folks to manually publish release, allowing the remaining unpublished documents to be published. Decided to exclude this work for now, because a lot of the publication logic is encoded into the publish button itself, making it tricky to extract into a different context. This is expected to be a very narrow edge case.

What to review

When there are errors present

The releases tool icon is given a small error indicator
Screenshot 2025-02-06 at 10 21 41
The releases list view will display an error indicator in the affected row
Screenshot 2025-02-06 at 10 23 04
The release detail view will show an error indicator at the start
Screenshot 2025-02-06 at 10 24 13
The release detail view will show an error detail UI
Screenshot 2025-02-06 at 10 24 46

Testing

  • Added unit tests.

Notes for release

Adds release error details to UI.

Copy link

vercel bot commented Feb 3, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
page-building-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 6, 2025 2:41pm
performance-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 6, 2025 2:41pm
test-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 6, 2025 2:41pm
2 Skipped Deployments
Name Status Preview Comments Updated (UTC)
studio-workshop ⬜️ Ignored (Inspect) Visit Preview Feb 6, 2025 2:41pm
test-next-studio ⬜️ Ignored (Inspect) Feb 6, 2025 2:41pm

Copy link
Contributor

github-actions bot commented Feb 3, 2025

No changes to documentation

Copy link
Contributor

github-actions bot commented Feb 3, 2025

Component Testing Report Updated Feb 6, 2025 2:44 PM (UTC)

❌ Failed Tests (1) -- expand for details
File Status Duration Passed Skipped Failed
comments/CommentInput.spec.tsx ✅ Passed (Inspect) 1m 6s 15 0 0
formBuilder/ArrayInput.spec.tsx ✅ Passed (Inspect) 12s 3 0 0
formBuilder/inputs/PortableText/Annotations.spec.tsx ❌ Failed (Inspect) 1m 20s 5 0 1
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx ✅ Passed (Inspect) 51s 11 7 0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx ✅ Passed (Inspect) 0s 0 12 0
formBuilder/inputs/PortableText/Decorators.spec.tsx ✅ Passed (Inspect) 26s 6 0 0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx ✅ Passed (Inspect) 14s 3 0 0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx ✅ Passed (Inspect) 27s 6 0 0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx ✅ Passed (Inspect) 1m 8s 15 0 0
formBuilder/inputs/PortableText/Input.spec.tsx ✅ Passed (Inspect) 1m 30s 21 0 0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx ✅ Passed (Inspect) 2m 2s 21 0 0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx ✅ Passed (Inspect) 13s 3 9 0
formBuilder/inputs/PortableText/Styles.spec.tsx ✅ Passed (Inspect) 26s 6 0 0
formBuilder/inputs/PortableText/Toolbar.spec.tsx ✅ Passed (Inspect) 1m 44s 21 0 0
formBuilder/tree-editing/TreeEditing.spec.tsx ✅ Passed (Inspect) 0s 0 3 0
formBuilder/tree-editing/TreeEditingNestedObjects.spec.tsx ✅ Passed (Inspect) 0s 0 3 0

Copy link
Contributor

github-actions bot commented Feb 3, 2025

⚡️ Editor Performance Report

Updated Thu, 06 Feb 2025 14:46:34 GMT

Benchmark reference
latency of sanity@latest
experiment
latency of this branch
Δ (%)
latency difference
article (title) 24.4 efps (41ms) 22.5 efps (45ms) +4ms (+8.5%)
article (body) 67.6 efps (15ms) 72.7 efps (14ms) -1ms (-/-%)
article (string inside object) 25.6 efps (39ms) 24.1 efps (42ms) +3ms (+6.4%)
article (string inside array) 23.3 efps (43ms) 20.8 efps (48ms) +5ms (+11.6%)
recipe (name) 47.6 efps (21ms) 43.5 efps (23ms) +2ms (+9.5%)
recipe (description) 52.6 efps (19ms) 50.0 efps (20ms) +1ms (+5.3%)
recipe (instructions) 99.9+ efps (7ms) 99.9+ efps (5ms) -2ms (-/-%)
synthetic (title) 18.3 efps (55ms) 18.2 efps (55ms) +1ms (+0.9%)
synthetic (string inside object) 20.0 efps (50ms) 19.2 efps (52ms) +2ms (+4.0%)

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark latency p75 p90 p99 blocking time test duration
article (title) 41ms 46ms 55ms 395ms 296ms 11.0s
article (body) 15ms 18ms 22ms 252ms 337ms 5.6s
article (string inside object) 39ms 41ms 45ms 168ms 426ms 7.1s
article (string inside array) 43ms 45ms 49ms 175ms 320ms 7.2s
recipe (name) 21ms 23ms 26ms 48ms 0ms 7.3s
recipe (description) 19ms 20ms 22ms 41ms 0ms 4.7s
recipe (instructions) 7ms 8ms 9ms 19ms 0ms 3.2s
synthetic (title) 55ms 58ms 69ms 174ms 1365ms 13.7s
synthetic (string inside object) 50ms 53ms 58ms 336ms 711ms 8.6s

🧪 Experiment result

The performance result of this branch

Benchmark latency p75 p90 p99 blocking time test duration
article (title) 45ms 52ms 82ms 465ms 1203ms 11.3s
article (body) 14ms 15ms 32ms 164ms 218ms 5.3s
article (string inside object) 42ms 43ms 44ms 173ms 571ms 7.6s
article (string inside array) 48ms 50ms 57ms 302ms 807ms 8.0s
recipe (name) 23ms 24ms 27ms 45ms 0ms 14.3s
recipe (description) 20ms 22ms 36ms 50ms 6ms 5.1s
recipe (instructions) 5ms 6ms 8ms 20ms 0ms 3.1s
synthetic (title) 55ms 58ms 60ms 270ms 1158ms 13.9s
synthetic (string inside object) 52ms 55ms 57ms 560ms 1466ms 8.7s

📚 Glossary

column definitions

  • benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
  • latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
  • p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
  • p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
  • p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
  • blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
  • test duration — how long the test run took to complete.

@pedrobonamin pedrobonamin force-pushed the feat/content-releases branch from a345b6f to 606f948 Compare February 4, 2025 14:34
Base automatically changed from feat/content-releases to next February 4, 2025 15:56
@juice49 juice49 force-pushed the feat/corel/release-bulk-action-error-states branch from bb7dacd to d009cf3 Compare February 4, 2025 16:36
@juice49 juice49 force-pushed the feat/corel/release-bulk-action-error-states branch from d009cf3 to 146c215 Compare February 5, 2025 12:02
@juice49 juice49 changed the title feat(sanity): load release document error field feat(sanity): display release errors Feb 6, 2025
@juice49 juice49 marked this pull request as ready for review February 6, 2025 10:45
@juice49 juice49 requested a review from a team as a code owner February 6, 2025 10:45
@juice49 juice49 requested review from ricokahler and jordanl17 and removed request for a team and ricokahler February 6, 2025 10:45
Copy link
Member

@jordanl17 jordanl17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only the one comment in the overview column defs where I think the condition might need to change. Otherwise 🌶️

description: 'undecided Error Release description',
},
error: {
message: 'An unexpected error occurred during publication.',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: more a musing and not blocking for this work, but I wonder how we can get these sorts of error messages to work with i18n. Perhaps in the future it best we avoid just passing through the message and focus on error types so we can localise them

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree in principle, however error.message reflects a technical error from the server and is not intended to be presented to the user in the UI (we do output it, for debugging purposes). When we know about other types of error that will be encapsulated here, we'll need to use some heuristic to show a relevant (localised) message in the UI.

@@ -0,0 +1,75 @@
import {describe, expect, it} from 'vitest'

import {NO_EMISSION} from '../../../../../test/matchers/toMatchEmissions'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👀

switchMap(({releases}) =>
from(releases.values()).pipe(
filter((release) => release.state === 'active'),
filter((release) => typeof release.error !== 'undefined'),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

COULD: roll this as a single filter, then since the check on state active and typeof error in used elsewhere too, could abstract that as some util... thinking maybe if the api simplifies or changes in the future that makes it easier

Copy link
Contributor Author

@juice49 juice49 Feb 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree it would make sense to abstract this to some guards:

function isActiveRelease(maybeActiveRelease): maybeActiveRelease is ReleaseDocument & { state: 'active' }
function isErrorRelease(maybeErrorRelease): maybeErrorRelease is ReleaseDocument & { error: { message: string } }

These could then be composed to abstract the logic around whether an error should be displayed.

Comment on lines 93 to 117
id: 'error',
sorting: false,
width: 40,
header: () => <Fragment />,
cell: ({datum: {error}, cellProps}) => (
<Flex
{...cellProps}
align="center"
paddingX={2}
paddingY={3}
sizing="border"
data-testid="error-indicator"
>
{typeof error !== 'undefined' && (
<Tooltip content={<Text size={1}>{t('failed-publish-title')}</Text>} portal>
<Text size={1}>
<ToneIcon icon={ErrorOutlineIcon} tone="critical" />
</Text>
</Tooltip>
)}
</Flex>
),
},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHOULD: we only want this to show for active releases, right? Either could return a different list of cols for active and archived; or perhaps could just add in the datum.state === 'active' check here too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very good point, thank you! I missed this detail 🤦‍♀️.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the code to simply perform a check on the cell datum, as you suggested. We should abstract this in the future, but I decided not to for now, as we're about to learn more about the errors that can be stored and our heuristics will possibly change.

@juice49 juice49 force-pushed the feat/test-rxjs-emissions branch from 7c02363 to c135ab5 Compare February 6, 2025 13:24
jordanl17
jordanl17 previously approved these changes Feb 6, 2025
Copy link
Member

@jordanl17 jordanl17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfecto

Base automatically changed from feat/test-rxjs-emissions to next February 6, 2025 15:51
@juice49 juice49 dismissed jordanl17’s stale review February 6, 2025 15:51

The base branch was changed.

@juice49 juice49 merged commit e728372 into next Feb 7, 2025
64 checks passed
@juice49 juice49 deleted the feat/corel/release-bulk-action-error-states branch February 7, 2025 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants